Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

added channels router #653

Open
wants to merge 1 commit into
base: tarantool_use_json
Choose a base branch
from

Conversation

zodeak
Copy link

@zodeak zodeak commented May 4, 2023

channels pub/sub can be routed to concrete tarantool instances

Proposed changes

added shards routing ability (for tarantool engine only)
clients can subscribe channels to subset of tarantool shards
each channel can be subscribed to multiple shards

at now all instances/shards are all the same and consistent hashing is used to select one of them
but we can have tarantool instances with different roles and each instance has its own set of channels

this patch adds flexible rules how to subscribe channels to shards

config example:

{
  "tarantool_address": ["shard1-addr1,shard1-addr2", "shard2-addr1,shard2-addr2"], // here we describe all avail instances
  "router": {
    "routes": [
      // here the rules to subscribe channels to exact tarantool shards
      {"name": "channel1", "addresses": ["shard2-addr1"]}, // (exact routing) any address of needed shard
      {"name": "channel2*", "addresses": ["shard1-addr1", "shard2-addr1"]}, // (the longest prefix routing) * means prefix, here we subscribe to two shards and will receive mesages from both shards
      {"name": "__default", ["shard2-addr1"]} // force to use default route if none was found
    ]
  }
}

presence/publish/history is not yet implemented

limitations for multi-shards routes:

publish cannot do it atomically, so duplicates will be if client re-publishes on error (if some of shards will die)

history cannot return just one StreamPosition, so new history api is needed (and what to do with old one?)

channels pub/sub can be routed to concrete tarantool instances
@FZambia
Copy link
Member

FZambia commented May 4, 2023

Hello, thanks for the pr.

I looked at the description and code – did not understand the motivation fully.

What I could understand - possibility to use custom sharding strategy based on channel instead of built-in consistent sharding. I.e. to pin Centrifugo to a particular Tarantool shard responsible for some channel.

But this PR adds more than that - subscriptions to multiple shards for the same channel - and that's sth I do not understand and which does not fit Centrifugo design where channel always corresponds to one shard. I doubt it makes sense for Centrifugo to add logic to the code base which is orthogonal to the design.

So we definitely can't proceed with this in the current form, probably if I understand the motivation to have multiple shards for one channel I will be able to suggest something. Or maybe not since it seems too different from the current model.

@FZambia
Copy link
Member

FZambia commented May 13, 2023

Strategy to discuss:

  1. Use shard channel to publish
  2. Use __сhannel field in Publication.Meta. This field has priority over the broker channel. Stripped when broadcasting to local clients.
  3. Func to re-match Publications with overloaded channel (probably not necessary)
  4. Sharded parallel processing by the overloaded channel name if possible

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants